Copying DIY instances

We often have both production and development versions of a DIY running at the same time. This page shows how to move both the DIY and SDS data from a production DIY to a development DIY. You can also use these instructions to replicate a DIY on your local workstation.

These tasks will only work if you can directly connect to the original mysql databases. For copying a database hosted on a server at CC that means you either need to be on an internal network or use SSH tunneling or a VPN.

1. dump the original's db
2. import the original's db into the copy's database
3. adjust the diy's settings to match the original's settings (sds.yml, db table prefix, application yml settings)

Edit config/database.yml to include a yaml hash for the remote database. The form of the value for adapter allows this config to be used under either ruby or jruby.

remote:
  adapter: <% if RUBY_PLATFORM =~ /java/ %>jdbcmysql<% else %>mysql<% end %>
  host: railsdb.concord.org
  database: rails
  username: rails
  password: *******
  table_prefix: udl_

Now executing the following rake task should delete the data in your current database, dump and copy the remote database to your local system, and then update the database.

$ rake diy:delete_copy_and_convert_db

If migrations now need to be applied run them with this command:

rake db:migrations

If you are not continuing with the next step of copying data from the original SDS to a new SDS instance run this task to recreate resources in the current SDS for the new DIY resources:

rake diy:delete_local_sds_attributes

Moving SDS locations

1. change the sds.yml to point to the NEW sds location information (create a portal, curnit and jnlp in the SDS, if necessary)
2. add the variable OLD_SDS_HOST to the environment.rb which points to the original SDS host url. Example:

   OLD_SDS_HOST="http://saildataservice.concord.org/5"

3. run the rake task

   "RAILS_ENV=production rake diy:migrate_sds_data"

   (setting RAILS_ENV=production makes it slightly faster, and also quiets the output tremendously).

You should now have a moved DIY instance.

Example ...

Here's what it looked like when I updated the data in the development version of the ITSi DIY:

[sbannasch@otto itsi]$ rake diy:delete_copy_and_convert_db
(in /web/rails.dev.concord.org/itsi)
Getting the stable database... done.

Your current database tables are about to be deleted and replaced
with the production database. Any data that only exists in your
current db will be lost. Are you sure you want to proceed? [Y/n] Y

Deleting tables in the current database............................ done.
Importing the stable database... done.
 1.
 2.

Previous database version: 54
Production database version: 53
*** The production database was older than your existing database. You should probably run 'rake db:migrate' to update your new database.

*** Don't forget to run rake diy:delete_local_sds_attributes

[sbannasch@otto itsi]$ sudo rake db:migrate
(in /web/rails.dev.concord.org/itsi)
== 54 AddNobundlesAttribute: migrating ========================================
-- add_column("itsi_activities", :nobundles, :boolean)
   -> 0.5415s
-- add_column("itsi_models", :nobundles, :boolean)
   -> 0.2433s
-- add_column("itsi_external_otrunk_activities", :nobundles, :boolean)
   -> 0.0597s
== 54 AddNobundlesAttribute: migrated (0.8451s) ===============================

[sbannasch@otto itsi]$ RAILS_ENV=production rake diy:migrate_sds_data
(in /web/rails.dev.concord.org/itsi)
This is intended to move data from one SDS to another. You should have already updated your sds.yml file to point to the *new* SDS.
Would you like to proceed? [y/N] y

This can take a long time (11m for a DIY with about 3500 users) for a DIY and associated SDS portal realm with lots of data.